There is a growing need for real-time data transfer on the Internet to support real-time applications such as, teleconferencing and live video. However, the Internet is not designed for real-time data transfer. Data is transferred on the Internet using Transmission Control Protocol(“TCP”)/Internet Protocol (“IP”). TCP/IP includes four layers, the application layer, the transport layer, the network layer and the link layer.
Data originates in the application layer, for example, the application data may be frames of a live video to be transmitted from a source node to a destination node. The transport layer includes the TCP protocol. The TCP protocol in the source node processes the frames of the live video into TCP data packets and assigns a sequence number to each packet of data. The TCP protocol in the destination node reassembles the TCP data packets transmitted by the source node using the data packet's sequence numbers.
The network layer includes the IP protocol. The IP protocol adds an IP address for the destination node to each TCP data packet. The size of the IP address added is dependent on the version of the IP protocol used. Version 4 of the IP protocol (“IPv4”) adds a 32 bit IP address to each TCP data packet. Version 6 of the IP protocol (“IPv6”), adds a 128 bit IP address to each TCP data packet. The Link layer in the source node sends the TCP data packets including IP addresses over the physical medium. The Link layer in the destination node receives the TCP data packets sent by the source node over the physical medium.
By dividing the application data into TCP data packets and providing the IP address for the destination node on each TCP data packet, each TCP data packet may travel on a different path between the source node and the destination node. Due to congestion in nodes along paths from the source node to the destination node, TCP data packets sent on different paths may not arrive in order.
For real-time data, for example, a live video the application can not wait until all the data packets are reassembled because the data packets are used as soon as they arrive at the destination node. If a data packet does not arrive at the destination node in time this delayed packet may be noticeable, for example, a delay in a data packet for live video may result in a loss of one or more frames of the video.
Extensions to TCP/IP have been proposed by the Internet Engineering Task Force (“IETF”) to add support for real-time data transfer. One proposed extension to provide in-order delivery of data packets for real-time data transfer between a source node and a destination node is Multiprotocol Label Switching (MPLS) described in “A Framework for Multiprotocol Label Switching” by Callon et al. in a Network Working Group Internet Draft published at http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-02.txt on May 21, 1998 incorporated herein by reference. MPLS adds a label to a data packet to guide the data packets through nodes along a pre-defined path in a network. The pre-defined path is called a Label Switched Path (“LSP”)Tunnel. LSP tunnels may be established using the Resource ReSerVation Protocol (“RSVP”) described in “Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification” by Branden et al. RSVP, Network Work Group, Request for Comment, 2205 published at http://www.ietf.org/rfc/rfc2205.txt on September 1997 incorporated herein by reference.
A “tunnel” in general, therefore, as used herein refers to a pre-defined path through networks. The “tunnel” may be established by RSVP or any other protocol now or hereafter established to support real time data transfer.
RSVP allows an application to reserve resources such as, bandwidth to transfer all TCP data packets originating in a specified application along a specified path between a source node and a destination node.
A disruption in service may occur in the tunnel, for example, due to a hardware failure in one or more nodes, or a connection between nodes, requiring the tunnel to switch data transfer to a new path between the source node and the destination node. Before the data transfer can commence on the new path resources must be reserved along the new path. The tunnel may also switch data transfer back to the old path, requiring resources to be reserved along the old path for example, after the hardware failure is repaired if the old path is better than the new path.
The tunnel's new path and the tunnel's old path may share intermediate nodes between the source node and the destination node. If the new path requests a resource reservation in a shared intermediate node before the old path has released the resource in the shared node, the resource is not available for the new path. If the old path releases the resource in the shared node the resource may be reserved by another path before the new path requests, the resource is not available for the new path. While the nodes in the new path are waiting for resources, data packets for the real-time application such as, live video are not being transmitted to the destination node.